Automatically generate floorplan test files after placement, and enhancements to cluster attraction groups #1938
Conversation
…e counting and fixed update of cluster attraction gains during clustering
…itions that represent halves of the grid, quadrants of the grid, etc.
…ug statements in placement and changed attraction group gain
…ded new options for generating constraints files, updated the way molecule gain is calculated for clustering
…o empty before the clusterer tries to pack it again. Added the code for this reset
…d comment for try_pack_molecule
…results of runs with no attraction groups. Changed AA_PACK_MAX_HIGH_FANOUT_EXPLORE back to its original value of 10
…which is used to generate constraints files
|
QoR Results for this pull request: |
…as not outputting constraints with the correct number of blocks
… is checked instead of just the first
…d during initial placement.
|
Please attach QoR data. |
| @@ -1076,6 +1076,8 @@ struct t_placer_opts { | |||
| float place_crit_limit; | |||
| int place_constraint_expand; | |||
| bool place_constraint_subtile; | |||
| int floorplan_num_horizontal_partitions; | |||
There was a problem hiding this comment.
Placer opts doesn't seem like the right place for this. Seems like a constraints opts structure would be worthwhile.
|
QoR results: |
|
|
||
| if (num_available_atoms < 500) { | ||
| for (AtomBlockId atom_id : group.group_atoms) { | ||
| const auto& atom_model = atom_ctx.nlist.block_model(atom_id); |
There was a problem hiding this comment.
Looks like duplicate code -- factor this and the code below into a helper function to avoid duplication (or more than one if necessary).
| return; | ||
| } | ||
|
|
||
| if (num_available_atoms < 500) { |
There was a problem hiding this comment.
Use a named constant instead of 500
| VTR_LOG("Floorplan regions are overfull: trying to pack again with more attraction groups exploration and higher target pin utilization. \n"); | ||
| attraction_groups.create_att_groups_for_overfull_regions(); | ||
| VTR_LOG("Pack iteration is %d\n", pack_iteration); | ||
| attraction_groups.set_att_group_pulls(4); |
There was a problem hiding this comment.
Think about using defined constants for all these numbers (2, 5, 4 ...). Can define in a block right above this code and comment what each does and why they have the values they do.
| type_count[i_col][j_row] = 0; | ||
|
|
||
| if (is_tile_compatible(tile, block_type)) { | ||
| if (is_tile_compatible(tile, block_type) && grid_tile.height_offset == 0 && grid_tile.width_offset == 0) { |
There was a problem hiding this comment.
// Legal anchor location to place this block.
|
|
||
| for (auto blk_id : cluster_ctx.clb_nlist.blocks()) { | ||
| if (place_ctx.block_locs[blk_id].loc.x == INVALID_X) { | ||
| VTR_LOG("Block %s (# %d) of type %s could not be placed during initial placement\n", cluster_ctx.clb_nlist.block_name(blk_id).c_str(), blk_id, cluster_ctx.clb_nlist.block_type(blk_id)->name); |
There was a problem hiding this comment.
Also print its floorplan constraint: say whether constrained or not, and what the constraint is.
Can also say if it is part of a placement macro, and if it is, give the other macro members and offsets.
|
Please add Titan QoR. |
|
Titan qor comparison: |
|
@vaughnbetz If the titan results look ok to you, is this ok to be merged? |
|
@vaughnbetz If the qor looks ok, can we merge this PR? I can address the comments asap on a second PR when this one is merged. |
|
Another run of the titan comparison: |
vaughnbetz
changed the title
|
Thanks @ArashAhmadian . @sfkhalid : can you comment? We really need to get the floorplan constraints working -- do you have any time to look at this in the near future? @saaramahmoudi has made a PR to make initial placement try to pack macros densely, which solves another issue. But I think there is still a fundamental bug in the attraction groups. |
|
@vaughnbetz @sfkhalid Yes, it would be great if this could be fixed soon :) . Also, BB wire length estimation is currently not getting logged (commented out in |
|
I don't know why that was commented out -- probably worth changing that back. It was confusing @jmah76 too. |
Thanks @ArashAhmadian. It is possible that there is a bug introduced in this branch, but I think the bug in the attraction groups is from code that was merged after this branch (not from this branch itself) because there were many tests I ran that used attraction groups that would pass on this branch but fail once I had merged in new code. I'll try to resolve the attraction groups issue in the coming week. For the commented out line, there is no particular reason for that, it can be added back in. |
Description
This pull request includes changes that fall under 3 main categories.
First, new routines were added to the vpr constraints writer files that allow that user to generate different kinds of floorplan constraints files. Specifically, they can generate floorplan constraints that consist of
a. two partitions that each take up half the grid
b. four partitions that each take up a quadrant of the grid
c. sixteen partitions that each take up a sixteenth of the grid
d. each cluster being put into its own partition and locked to its previous spot on the grid
Second, changes were made to how the clusterer picks new molecules as candidates for the current cluster that is being packed. Specifically, the molecule gain is increased for molecules that have the same attraction group as the cluster, and decreased for molecules that do not have the same attraction group as the cluster.
Third, new checking routines were added to the clustering and placement stages to give insight on why vpr runs might fail when being run with constraints. Specifically, these routines give insight on which floorplan regions are overfilled, and by how many clusters.
Related Issue
Related to the changes being made to implement placement constraints in VPR - see issue #932 for more information